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Scope 



The present document contains general guidance on (User) ENUM implementations as defined in RFC 3761 [16] and in 
TS 102 051 [2] "ENUM Administration in Europe" and the specification for: 

• The format, contents and meaning of the information in the NAPTR records that are held by the ENUM Tier 2 
Nameserver providers and accessible by DNS. 

• The ways in which ENUM client software should interpret and act upon information obtained from NAPTR 
records. 

The present document is intended to enable interoperability between ENUM implementations that are organized in 
different countries. This interoperability enables: 

• The same ENUM client software to work with NAPTR records generated by different national 
implementations and this in turn will enable applications that use ENUM to access details of ENUM 
subscribers in more than one country without additional modifications. 

• Organizations to function as ENUM Registrars and ENUM Tier 2 Nameserver Provider in more than one 
national implementation. 

The present document will therefore add economies of scope to the ENUM implementations that will benefit ENUM 
subscribers, providers, application service providers and ENUM users. 

The present document is Version 2 of the Technical Specification (TS) and incorporates already some results obtained 
from trials performed in some countries. It may serve therefore with some caution also as a basis for first commercial 
deployments, keeping in mind that still not all enumservices are available as IETF RFCs and registered with lANA, 

The intention is to review the present document based on the experience gained from future implementations and if 
necessary. 
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NOTE 2: Also some of the above referenced URI Schemes are currently in the process of being updated. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 051 [2], with the exception of 
ENUM End User and ENUM Subscriber and the following apply: 

NOTE: The term ENUM End user is not used within the present document, ENUM User and ENUM Subscriber 
are defined as follows. 
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ENUM Subscriber: assignee of an E.164 number who has agreed to insert its E.164 number in the ENUM DNS-based 
architecture and who requests population of an ENUM domain 

NOTE: The ENUM subscriber has full control over the provision and content of the N APTR Resource Records in 
the ENUM Tier 2 Nameserver provider. The ENUM Subscriber is called ENUM End User in 
TS 102 051 [2]. 

ENUM User: person or entity who is querying the ENUM DNS-based architecture using an ENUM-enabled 
AppUcation Client or an ENUM Client 

NOTE: The ENUM User may be aware only of the application and not of the use of ENUM by the application. 

In addition, the following terms and definitions apply: 

Application Client: function that provides a user access to the Application Server, e.g. a VoIP client or e-mail client 

Application Server: function provided by an Application Service Provider to communicate with the Application Client 

Communication Service Provider (CSP): any entity providing communications services using E.164 numbers to "End 
Users" and using an infrastructure to provide routing capabilities 

NOTE: The "End Users" may be on the Internet, within an IMS based NGN or even on the PSTN. 

ENUM Client: function that provides access to the DNS which will then return information in the form of NAPTR 
records 

NOTE: This could take several forms e.g. it may reside as client software on an intelligent terminal used directly 
by the ENUM User or be network based, provided upstream as part of the facilities offered by an 
Application Service Provider. 

ENUM Client Supplier: entity supplying the ENUM Client 

ENUM enabled Application Client: Application Client querying ENUM directly for NAPTR Resource Records 

ENUM enabled Application Server: Application Server that is using ENUM Clients as part of their application, 
e.g. an email server that translates phone numbers in the To:/RCPT fields into their ENUM stored mailto: values 

"ENUMservice": parameter held in the Service Field of a NAPTR Resource Record associated with the ENUM DDDS 
Application that indicates the class of functionality a given URI Scheme offers 

NOTE: According to RFC 3761 [16] an "ENUMservice" is defined in an RFC and officially registered with 
lANA (see http://www.iana.org/assignments/enum-services). 

The following "ENUMservices" are currently registered with lANA: 

sip RFC 3764 [24] 

h323 RFC 3762 [23] 

The following "ENUMservices" are in contained in the following I-Ds: 

voice: sip 

voice:h323 

voice:tel draft -brandner-enumservice-vovi-02 

video: sip 

video:h323 

video:tel draft-brandner-enum-service-vovi-02 

email:mailto draft-ietf-enum-msg-03 

fax:tel draft-ietf-enum-msg-03 

sms:tel draft-ietf-enum-msg-03 

sms:sip 

sms:sips 

sms:mailto draft-ietf-enum-msg-03 

ems:tel draft-ietf-enum-msg-03 

ems: sip 

ems: sips 
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ems:mailto 


draft-ietf-enum-msg-03 


mmsitel 


draft-ietf-enum-msg-03 


mmsisip 


- 


nuns: sips 


- 


mms:mailto 


draft-ietf-enum-msg-03 


ifax:mailto 


draft-ietf-fax-faxservice-enum-03 


web:http 


draft-ietf-enum- webft-0 1 


web:https 


draft-ietf-enum- webft-0 1 


ft:ftp 


draft-ietf-enum- webft-0 1 


pres 


draft-ietf-pres-01 


ann:sip 


- 


ann:h323 


- 


ann:tel 


- 


ann:http 


- 


ann:ftp 


- 


enum 


- 


void:mailto 


draft-ietf-enum- void-0 1 


void:http 


draft-ietf-enum- void-0 1 


void:mailto 


draft-ietf-enum- void-0 1 


loc:http 


- 


key:ldap 


- 


key:http 


- 



Infrastructure ENUM: Infrastructure ENUM is about publishing the information with E.164 numbers that a 
Communication Service Provider (CSP) is hosting to either a group of selected peers or to all other CSPs. 

Naming Authority Pointer Resource Record (NAPTR): DNS Resource Record type specified in RFC 3403 that can 
be used to generate URIs 

Resource Record: element within the Domain Names System (DNS) containing a data item associated with a domain 
name 

Uniform Resource Identifier (URI): compact string of characters for identifying an abstract or physical resource 
(e.g. an application) 

NOTE: An URI is used within a NAPTR Resource Record to point to a specific application. 

Uniform Resource Identifier (URI) Scliemes: In the Uniform Resource Identifier (URI) definition (RFC 3986, 
RFC 1738) there is a field, called "scheme", to identify the type of resource. 

NOTE: URI Schemes are defined in RFCs and officially registered with the lANA 
(see http://www.iana.org/assignments/uri-schemes ). 

The following registered URI Schemes are used within the present document: 



ftp File Transfer Protocol 

http Hypertext Transfer Protocol 
mailto Electronic mail address 
sip, sips Session Initiation Protocol 
tel Telephone 



RFC 1738 [7] 
RFC 2616 [13] 
RFC 2368 [11] 
RFC 3261 [17] 
RFC 3966 [14] 



Idap Lightweight Directory Access Protocol RFC 2255 [10] 

https Hypertext Transfer Protocol Secure RFC 2818 [15] 

h323 H.323 URL Scheme Registration RFC 3508 [22] 

pres Presence (presentities) RFC 3861 [25] 

im Instant messaging Instant Inbox) RFC 3861 [25] 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

+NNN Any E. 164 number e.g. in the format +12345678900 

CNAME Canonical Name DNS Resource Record 

DDDS Dynamic Delegation Discovery System 

DNAME DNS RR for non-terminal DNS Name Redirection 

DNS Domain Name System 

DNSSEC DNS SECurity extension 

EDNS Enhanced Domain Name System 

EMS Enhanced Message Service 

FAX Facsimile Service 

FTP File Transfer Protocol 

H323 Protocol defined in ITU-Recommendation H.323 

lANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

IP Internet Protocol 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

LDAP Lightweight Directory Access Protocol 

MMS Multimedia Messaging Service 

NAPTR Naming Authority PoinTeR 

NICNAME Unique Identifier ("handle") pointing to personal information in WHOIS 

NRA National Regulatory Authority 

POSIX Portable Operating System Interface 

PSTN Public Switched Telephone Network 

RegExp Regular Expression 

RFC Request For Comment 

RIPE/NCC Reseaux IP Europeens Network Control Centre 

RR (DNS) Resource Record 

SIP Session Initiation Protocol 

SMS Short Message Service 

SW Software 

URI Uniform Resource Identifier 

VoIP Voice over IP 

WHOIS A tool (program) to look up domain names and related information in a database 



Introduction 



Following initial work on the national ENUM trials that are either being planned or taking place in several European 
countries, it has been recognized that additional benefits can be gained by facilitating interoperability of the various 
trials. Version 1 of the present document aimed to assist those countries who wished to expand their trials on a 
pan-European basis. It proposed a minimum set of requirements for interoperability. 

ENUM Trial interoperability enabled benefits to be gained by sharing experience of different administrative, technical, 
operational and user aspects relating to the provision of ENUM capabilities between countries. Each country has its 
own particular architectural, administrative, security and authentication requirements along with its particular 
implementation rules. Therefore linking the trials together enabled the various approaches to be evaluated on a broad 
basis. This approach also widened the range of applications and services available to end users as it enabled them to 
access those provided by other trialists. 

Without commonality of some aspects especially as the format of the NAPTRs designed to support applications, 
attempts to link trials together are likely to result in difficulties when trying to access user information in more than one 
country. 

The results collected from pan-European trials enabled the participants to gain valuable information and experience that 
now assists as commercial deployment is considered within some countries. The present document is therefore updated 
to Version 2 to incorporate the gained experience during the trials and make it available for commercial 
implementations. 
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In order not to presume any implementation solution, it is necessary that the minimum sets of requirements will not 
limit the freedom of individual implementations and the possibility to take different approaches. 

The range of functional entities participating in a national implementation depends on the choice of the administrative 
model in the country involved. The preferred model in a given country, in turn, depends on, among other things, the 
national arrangements for the management of domain names and E.164 numbers. TS 102 051 [2] outlines a number of 
options for the administrative model and explains the functions of these roles. Nonetheless, most of the roles (functional 
entities) listed are expected to be present in all national implementations irrespective of the chosen administrative 
model: 

ENUM Tier Registry. 

ENUM Tier 1 Registry. 

ENUM Tier 2 Nameserver Provider. 

ENUM Registrar. 

Application Service Provider. 

Authentication Agency. 

ENUM Subscriber. 

ENUM User. 

For more general information on ENUM see TS 102 051 [2]. 

5 General objectives of ENUM implementations 

Although the objectives for ENUM implementations undertaken within any country must remain totally a national 
matter, it should be recognized that additional benefits may be gained from shared experience if some of the general 
objectives are shared. Such experience can be further enhanced if different implementations are linked together. 

The following list of objectives identifies those that fall into this category and is recommended for implementations that 
are linked together in order to share their ENUM experience: 

• Understanding the ENUM technology and its potential in providing new applications and services to 
customers. 

• Evaluating basic DNS infrastructure in relation to ENUM architecture models (for example ENUM Tier 1 
Registry, ENUM Registrar, ENUM Tier 2 Nameserver Provider, Authentication and Validation procedures). 

• Evaluate and refme the economic benefits and costs of introducing the ENUM capability. 

• Exchange of information related to processes e.g. provide process, change process, cessation process, dispute 
process. 

• Increase the overall size and thereby the benefits of European trials. 

• Provide feedback to the relevant standard bodies. 

• Provide feedback to NRA/Governments. 

Additionally the following list identifies aspects where additional benefits are likely to be gained, although their 
inclusion should be dependent upon each specific case and should remain a national issue: 

• Experience of registering the ENUM domain name related to the E.164 number and the entry of the necessary 
data into DNS zone files. 

• Validation initiated by the ENUM Registrar (that the correct delegation is made to the ENUM Subscriber). 
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• Gaining experience in provisioning ENUM delegation processes between ENUM Registrars and ENUM Tier 1 
Registries. 



• 



Exploring options for harmonized provisioning protocols across different countries as well as for unified 
validation processes. 

Experience of sharing a common set of applications (e.g. VoIP) from a wider set of users. 



6 Interoperability of ENUIVI implementations 

This clause analyses the issues of interoperability and the constraints on the different roles of the parties involved in 
ENUM implementations. 

6.1 Constraints in national implementations 

The ENUM Subscriber in a national implementation needs to have an E. 164 number in the country concerned.. Since 
DNS is open, the data relating to all ENUM subscribers is visible to any Application Service Provider or ENUM User in 
any country. 

The ENUM Registrar acts as an agent to input the ENUM Subscriber's ENUM domain name (E.164 number) into the 
ENUM Tier 1 Registry so that the Registry points to the correct ENUM Tier 2 Nameserver Provider in DNS. The 
ENUM Registrar needs to be appointed or recognized by the ENUM Tier 1 Registry. The ENUM Registrar may also 
have access to the ENUM Tier 2 nameserver to load, amend and delete NAPTR records in the format being used by the 
country concerned, or the ENUM Subscriber may load, amend and delete the NAPTR records directly with the 
nameserver themselves. Thus the ENUM Registrar's role is nationally specific, although the Registrar may be located 
anywhere. 

The ENUM Tier 2 Nameserver Provider holds the NAPTR records in the format being used by the country 
concerned. The ENUM Tier 1 Registry for the country concerned needs to point to that nameserver. The nameserver 
may be located anywhere. 

The ENUM Client Supplier is required to support the format of the NAPTR records used in the national 
implementation because their ENUM Clients need to be compatible with the NAPTR records. ENUM Clients may be 
embedded in Application Clients or Application Server or may be run as simple stand-alone applications. If an ENUM 
Client supported only the NAPTR formats used in a particular national implementation, and if the NAPTR records have 
different formats for different implementations then different versions of the application would be needed to work with 
ENUM Subscribers in more than one country. This is impractical. Thus in practice there is strong pressure to ensure that 
a common set of NAPTR formats are uses between implementations. 

The Application Service Provider may use ENUM Clients as part of their application. The Application Service 
Provider using ENUM may be located anywhere, even in a country that is not running an ENUM trial at all. An 
Application Service Provider not using ENUM is out of scope of the present document. 

The ENUM User may be located anywhere but, depending on the application, may need special Application Client 
software. 

Figure 1 shows the relationships involved for two different national implementations and for a common model of the 
relationship between ENUM Tier 1 Registry, ENUM Registrar and ENUM Tier 2 Nameserver Provider. The ENUM 
Subscriber establishes their ENUM entry through the ENUM Registrar who loads this information into the NAPTR 
records held by the ENUM name server at Tier 2 level. (Alternatively the ENUM Subscriber may give this information 
directly to the ENUM Tier 2 Nameserver Provider). The ENUM Registrar then asks the ENUM Tier 1 Registry to 
create NS records for the ENUM Subscriber's ENUM domain name (associated with their assigned E.164 number) to 
point to the nameserver that holds the NAPTR records. An ENUM User uses an ENUM Client, either directly or as part 
of an ENUM enabled Application, to query the NAPTR records to find the information for the ENUM Subscriber with 
whom they wish to communicate. After obtaining the NAPTR records the ENUM User or their application may use this 
information to establish the communications between the ENUM User and the ENUM Subscriber. 

An ENUM User may either use the ENUM Client directly or use an Application Client. The Application Client in turn 
may either use the ENUM Client directly or forward the request to an Application Server, who may use an ENUM 
Client to query ENUM on behalf of the user. 
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Figure 1 : Relationships involved for ENUM Interoperability 

Thus there are two constraints on interworking that can be removed by further action: 

• Recognition of an ENUM Registrar in more than one national ENUM implementation. This would enable an 
ENUM Registrar to participate in multiple ENUM implementations. It would not, however, allow the ENUM 
subscribers who are customers of the ENUM Registrar in country A to be ENUM Subscribers in a country B if 
their E.164 number is in the national numbering plan for the country A. In other words, participation as an 
ENUM Subscriber is linked to the number range for which the ENUM Tier 1 Registry and ENUM Registrar 
are responsible. 

• Lack of standardization of the NAPTR records, which: 

Ties ENUM Clients to specific national implementations. Standardization would enable applications 
with a single version of client software to work with all implementations. 

Ties the operation of the name server on the Tier 2 level and its data entry and updating to specific 
national implementations. Standardization would facilitate the use of the same Tier 2 provisioning 
system in more than one implementation. 

The present document focuses on the standardization of the NAPTR records because: 

• Recognition of the ENUM Registrar is a non-technical and national matter. In the longer term, consideration 
could be given to the potential benefits of harmonizing the interfaces between the ENUM Registrar and the 
ENUM Tier 1 Registry and ENUM Tier 2 Name Server. 

• Removing the constraint does not remove the limitation imposed by the E.164 number being linked to a 
particular national numbering plan. 
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6.2 Interoperability in ENUM implementations 

Thus the main problem for interoperability arises from the lack of standardization of the "ENUMservice" field of the 
NAPTR records. If different formats and information are used in different implementations, then the client software will 
work with only one national implementation and this will limit the use of the applications or cause them to incur 
additional costs in running multiple versions of client software. 



The situation is summarized in table 1 . 



Table 1 





Constraint on 
location 


Relationship to 

national 
Implementation 


Benefits of 

standardizing the 

NAPTR records 


Value of 

standardization of 

NAPTR records 


ENUIVI Subscriber 


Participation in a 
national 

implementation is 
linked to having an 
E.164 number in the 
number range covered 
by the national 
implementation and for 
national numbers this 
implies fulfilling the 
eligibility requirements 
for that national 
implementation, which 
may include being 
resident in the country 


Registrant (also known 
as Subscriber) 


The data held in DNS 
is usable by more 
ENUM clients 


Medium 


ENUM Registrar 


Anywhere in the world 


ENUM Registrar 

Needs technical 
compatibility with other 
implementation 
partners and 
subscribers and may 
include possible 
contractual and/or 
accreditation 
procedures 


If the registrar updates 
the NAPTR records 
then it can work with 
nameservers in more 
than one country and 
so can act as registrar 
for more than one trial 


Medium 


ENUM Tier 2 
Nameserver Provider 


Anywhere in the world 


Implementation 
participant 

Needs technical 
compatibility with other 
Name Server 
implementations 

Needs compatibility 
with the ENUM client 
software 


The provisioning 
system can support 
implementations in 
more than one country 


Medium 


ENUM Client Supplier 


Not relevant 


Not necessarily related 

Client software needs 
to be compatible with 
the ENUM Tier 2 
nameserver 


Client software can 
work without 
modifications in all 
countries 


High 


Application Service 
Provider that uses 
ENUM 


Anywhere In the world 


Not necessarily related 

Needs to use client 
software compatible 
with the ENUM Tier 2 
nameserver 


Application can be 
compatible with all 
implementations with 
the same client 
software 


High 
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Constraint on 
location 


Relationship to 

national 
Implementation 


Benefits of 

standardizing the 

NAPTR records 


Value of 

standardization of 

NAPTR records 


ENUM User 


Anywhere in the world 


Not related 

Needs either: 
Client software 
compatible with the 
ENUM Tier 2 
nameserver, or 
software compatible 
with the application 


Can use the 
application with a 
larger group of ENUM 
subscribers 


Medium 



7 Administrative requirements for interoperability of 

ENUIVI implementations 

The following is set out as basic administrative requirements that have the objective of engendering a high level of 
confidence between different implementations of ENUM: 

For each implementation: 

• National ENUM domains SHALL have been delegated from Tier level to Tier 1 level according to the 
interim procedures as currently determined by the ITU-T. 

• Operational and administrative processes SHALL be in place according to clause 11 of TS 102 051 [2]. 

• An open interface between ENUM Tier 1 Registry and ENUM Registrar. 
NOTE 1: Interface likely to be different in different implementations. 

• All ENUM domain names (associated with assigned E.164 numbers) inserted SHALL have been validated in 
accordance with the principles in TS 102 051 [2]. 

• Ability to insert as a minimum geographic numbers in ENUM. 
NOTE 2: Abihty to insert numbers in ENUM as defined by the NRA. 

• WHOIS type capabiUty: 

NOTE 3: WHOIS is a tool that is used to look up domain names and related information in a database. It is used 
within gTLDs and ccTLDs Registries to look up e.g. second-level domain information. The primary use 
is to look up the availability of a domain name. The additional information provides e.g. domain name 
holder, administrative contact, technical contact, zone contact, billing contact, nameservers used and 
unique identifiers pointing to personal information (NICNAME). 

• Within the ENUM domain name spaces in el64.arpa. associated with the nationally delegated portions of the 
E. 164 number space, a WHOIS type capability may be used to provide similar information for registered 
ENUM domain names (associated with assigned E.164 numbers) at the ENUM Tier 1 Registry level. Whether 
or not such a facility is permitted or required is a national issue, as is any requirement to allow individual 
registrants to restrict publication of their personal data by this means. 

• Adequate data protection safeguards are essential in the interoperating implementations. In countries that 
implement EU legislation, trials SHALL implement procedures that ensure compliance with national laws 
corresponding to the EU Data Protection Directives. In other countries, implementations SHOULD implement 
procedures that are consistent with the EU Data Protection Directives except where this conflicts with national 
laws. 

NOTE 4: All ENUM subscribers must be made aware that once the contents of their registration are inserted within 
ENUM, they may be publicly available and contractually agree to this in order to ensure their privacy 
right are protected. 
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• all ENUM implementations SHALL define policy objectives and SHALL adhere to the procedures defined for 
the national ENUM implementations. 

8 DNS requirements for interoperability of ENUIVI 

The following are proposed as minimum common DNS requirements for ENUM implementations: 

• For interoperability of ENUM implementations, the global DNS server hierarchy SHALL be used, so they 
SHALL use public DNS servers within the normal hierarchy; these are ENUM Trials using delegations in 
el64.arpa by RIPE/NCC according to the interim procedures defined by ITU- and according to TS 102 051 [2] 
and the present document. 



• 



• 



ENUM DNS Nameserver operation SHALL be implemented according to RFC 1034 [3], RFC 1 123 [5], 
RFC 1591 [6], RFC 2181 [8] and RFC 2182 [9]. 

ENUM delegations at the ENUM Tier 1 Registry point to the ENUM Tier 2 name servers which must be 
authoritative for that zone. 

Name servers MUST not run insecure name server software and SHALL be protected against security 
penetration attacks. 

DNS Servers used as Authoritative (Tier 2) servers in ENUM implementations SHOULD support TCP 
requests. Although such support is not required, there are significant limitations that are introduced in terms of 
the data that can be "published" for ENUM subscribers by lack of such support. 

DNS Servers used in ENUM implementations SHOULD understand and support queries with the EDNSO 
"extended length" option flag set. In particular, if the DNS server does not support TCP requests, then it 
SHALL support this flag and respond as requested. 

Conventional DNS responses are limited to 512 bytes. When a reply to a DNS query exceeds this, the server 
sends a truncated response. The client then makes a TCP connection to the server and repeats the query to get 
the entire response. This is bad because busy name servers could be overwhelmed by many thousands of 
short-lived TCP sessions. Clients also suffer due to the latency caused by setting up and tearing down the TCP 
connection. 

It is likely that an ENUM lookup could return several NAPTR records, exceeding this 512 byte limit. If Secure 
DNS is involved, responses are guaranteed to exceed 512 bytes because of the resource records defining 
signatures and public keys that will be returned. 

The EDNSO protocol defined in RFC 2671 [26] can be used to eliminate these problems. Most name server 
implementations support this protocol extension. With EDNSO, clients can indicate the amount of data they are 
willing to accept in a UDP response without truncation. Name servers can then return responses of say 2K or 
4K without truncating their replies which would trigger lookups over TCP. 

To ensure a basic level of conformance, adherence to the following points is recommended: 

Name servers should have sufficient capacity to support reasonably high query rates. 

Name servers should be protected against denial of service attacks. 

Appropriate logging and audit trails should be established for name servers. 

Name servers should be installed in co-located facilities with 24x7 monitoring, backup power supplies, 
etc. 
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9 Harmonization of the "ENUIVIservice" field in the 

NAPTR Records 

9.1 Background to minimum requirements for NAPTR use 

The process of approving RFCs that specify ENUMservices is new, and is still time consuming. At present, several 
ENUMservices have been approved, and several more are in the approval process. It is expected that the period needed 
for approval will improve with experience with the process. 

Within an ENUM implementation, the provisioning system needs to make assumptions about the "ENUMservices" 
fields and the "URI schemes" used within an Application, and vice versa. If different ENUM implementations make 
different assumptions, then these assumptions made differ. This could result in components that are incompatible 
between implementations. 

To avoid this, a consistent set of "ENUMservices" fields are defined within the present document. Any ENUM 
implementation and ENUM Client SW implementing this set of "ENUMservices" fields is guaranteed to be compatible 
to any other ENUM implementation and ENUM Client SW also implementing this set. 

The "ENUMservice" fields defined in the present document will be forwarded to the IETF ENUM WG as Internet 
drafts containing registration templates according to RFC 3761 [16] to be discussed and approved as RFCs for 
registration of the "ENUMservice" fields with lANA. 

A Registration Template needs to contain the following information. 

ENUMservice Name: 

Type(s): 

Subtype(s): 

URI Scheme(s): 

Functional Specification: 

Security considerations: 

Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 

Author: 

Any other information that the author deems interesting: 

Since the Internet Drafts forwarded to the IETF may be modified during the following discussion, there is no guarantee 
that the "ENUMservices" finally registered with lANA are identical with the "ENUMservices" in the European 
implementations as specified within the present document. 

Consideration may be given to updating the present document after a certain time periods if necessary and to align it to 
the "ENUMservice" fields finally registered RFC with lANA. 

9.2 General conditions 

The minimum requirements for interoperability are: 

• ENUM clients SHALL assume that the DNS Infrastructure for ENUM is available in the domain el64.arpa. 

• The ENUM domain names associated with any given E. 164 number SHALL be accessible from any client 
using the standard technical mechanisms specified in RFC 3761 [16] and RFC 1035 [4]. 

• ENUM Subscribers SHALL provide at least one URI (e.g. e-mail, web), using any Application Service 
Provider. 

• The ENUM client SHALL be able to query the domain evaluated for recordtype NAPTR. 

• If the response code of the query is NOT or 3, the ENUM client SHALL return "query failed". 

• If the response code of the query is 3 (Name Error, no such domain, NXDOMAIN), the ENUM client SHALL 
query the enclosing zone returned in the authority section of the response for recordtype NAPTR. 
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• If the query of the enclosing zone returns NAPTR records, these NAPTR records SHALL be evaluated in the 
same way as described below as if these NAPTRs had been retrieved by the original query (i.e. an eventual 
regular expression SHALL be evaluated with the original AUS). 

• If the original query or the query of the enclosing zone as described above returns no NAPTR RR, the client 
SHALL proceed as described in clause 10. 

• If the response code of the query is (No error condition) and NAPTR RR are returned, these NAPTR RR 
SHALL be evaluated as described below. 

• NAPTR records SHALL be formatted according to RFC 3403 [20]/RFC 3761 [16] and the "ENUMservice" 
field SHALL be used as defined in the present document. 

• The NAPTR Resource Records SHALL be understandable (and be capable of being processed) by any ENUM 
Client. This has several aspects: 

The entity publishing the Resource Record and the entity querying the Resource Record SHALL have a 
common understanding of the meaning stored in that Resource Record. 

To achieve this, within the ENUM implementations a common (basic) set of "ENUMservices" is agreed 
that MAY be expected within the service field of an ENUM NAPTR Record. The "ENUMservices" 
define also a common (basic) set of URI Schemes. 

The list of "ENUMservices" and "URI Schemes" used is limited to the set defined in clause 9.4. 

This does NOT mean that every ENUM Client SHALL support all of the "ENUMservice" fields that are 
in this set, but instead that it SHALL recognize the meaning of these values and common defined 
behaviour (see note below) SHALL be provided for "ENUMservices" and URI Schemes which are not 
recognized by the ENUM Clients. 

Note that this list is a requirement for interoperation. However, it is perfectly valid for other applications to be tested 
within individual implementations and thus for Resource Records indicating these applications to exist within an 
ENUM domain that is part of such an implementation. As the content of the ENUM domain is physically accessible 
from anywhere, an ENUM Client may receive Resource Records containing application indicators that it does not 
support or recognize, complex RegExp fields, or even non-terminal NAPTRs. 

Clients should be designed to expect receipt of such records. They should have a defined behaviour when encountering 
Resource Records that they cannot understand, a defined behaviour when encountering Resource Records that indicate 
service features that they cannot support, and defined behaviour when encountering non-terminal NAPTRs or problems. 
It is important that an ENUM Client should be able to recognize a complex RegExp field, and should not attempt to use 
the partially evaluated result if it does not support fully regular expression processing. 

• An ENUM client SHALL be able to convert an entered E. 164 number in the format H-NNN according to the 
rules given in RFC 3761 [16] clause 2 into a domain name ending in el64.arpa. 



• 



The DNS Resolver used by the ENUM Client will process any CNAME or DNAME Resource Records 
transparently. 



9.3 Format and processing of NAPTR records 

The NAPTR records SHALL be in the format as defined in RFC 3403 [20] and contain the following fields: order, 
preference, flags, services, regexp and replacement (see annex A). 

For interoperability of the ENUM implementations, the following simplifications are recommended: 

• The ENUM cUents MAY ignore all NAPTR records except those with Flag "U". The flag field value should 
always be "U" and never blank, so the NAPTR result need not to be re-submitted and loops are easily avoided. 
It follows from this that the replacement field will always be empty. 

• The Order field for all NAPTRs within a single ENUM domain SHALL be set to the same value 100. 

• The Preference field MAY be used by the ENUM Subscriber as a recommendation to the order in which the 
contacts should be presented to the ENUM user. The ENUM client MAY order the list of NAPTRs using the 
Preference field; however it is not required to do so. 
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The regular expression field SHALL use the "!" character as a delimiter. 

The regular expression SHALL not include the case insensitive flag "i" at the end of the field. 

As a minimum, an ENUM Client need not be able to process NAPTRs that include "complex RegExps", 
meaning RegExp fields that have consequent parts that are dependent on the matching part (i.e. where a string 
of form "\1" is included), and this part is not just a literal string holding the URL If unable to process "complex 
RegExp" fields (i.e. ones in this format), it should nevertheless be able to detect the presence of such a 
"complex" pattern and reject the NAPTR, and MUST not attempt to use this string. 

The RegExp field is in two parts; a matching part followed by a consequent part. Unless unavoidable, the 
matching part SHOULD include only a fully matching pattern, with the consequent part holding a complete 
replacement, without re-using matched patterns (i.e. "simple RegExps" should be used wherever possible). 
These "simple" patterns can be considered as a command to "throw away the input string and replace by the 
literal string held in the consequent part". In the format of the regular expression field, this would appear as 
"!'^.*$!full-uri!" (where "full-uri" holds the target URI string). 

• An ENUM client is not required to support queries including the EDNS "extended length" option. 

NOTE: Although not required, support for the EDNSO option flag is recommended where possible, as 

resubmitting a query using TCP takes time, and this delay can be avoided if the initial query has this flag 

set. 



• 



• 



• 



To support ENUM Clients that do not support use of the EDNS "extended length" option in conjunction with 
ENUM DNS Servers that do not provide service using TCP, the space available for returned resource data 
should be limited to ca. 500 octets. 

As a result, the maximum number of NAPTRs populated in any queried subdomain should be limited to fit 
into this space - this equates to a limit of approximately 5 NAPTRs per ENUM domain, unless DNSSEC is 
used. 

Any ENUM Client should expect, however, to receive truncated responses and should act accordingly. It 
should also expect the DNS Server holding the ENUM data to not provide service using TCP. 

ENUM Clients should check for presence of more than one "+" in the ENUM services field and understand 
this to mean that there is more than one "ENUMservice" defined for this record. 

It is suggested that a NAPTR with more than one "ENUMservice" type should be displayed as a number of 
values, each supporting one "ENUMservice" field. In effect, the NAPTR is converted in the Client to a number 
of "NAPTRs", each with a single "ENUMservice". 

• Note that if the NAPTR includes more than one "ENUMservice" field, then if the URI-scheme differs between 
the ENUMservices, or the URI scheme is different from that shown in the Regular Expression field, then the 
NAPTR is incorrect and MUST be rejected by the client. 

• Note that there is an exception to this - if a NAPTR has an ENUMservice sip or ENUMservice h323, then as 
these are tied to the URI scheme, there cannot be a NAPTR with, for example, E2U+sip+h323, as this would 
imply that the NAPTR contained more than one URI. 

A number of general recommendations are given in the IETF document I-D draft-ietf-enum-experiences (see 
bibliography). It is recommended that if the IETF publishes a RFC based on earlier drafts of draft-ietf-enum- 
experiences, this SHALL be followed. Prior to this the latest draft-ietf-enum-experiences SHALL be followed. 

9.4 "ENUMservices" and associated URI Schemes 
9.4.1 IVIinimum set of "ENUIVIservices" 

All "ENUMservice" fields SHALL be in the format "type: subtype" as defined in RFC 3761 [16], with the exception of 
the "ENUMservices" "sip", "h323", and "enum", which have only a "type". 

Note that the "subtype" shown in the following list is always a copy of the URI scheme held in the NAPTR (duplicated 
from the consequent part of the RegExp field). 
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9.4.1 .1 "ENUMservices" for Interactive Media-stream Exchange 

This group of "ENUMservice" fields indicates that the associated resource can be used for interactive (media stream 
exchange) calls. 

Voice services 

• voice: sip 

• voice:h323 

• voice:tel 

These "ENUMservices" indicate that the resource identified by the associated URI is capable of being contacted to 
provide a communication session during which interactive media streams carrying voice data can be exchanged. 

Video services 

• video: sip 

• video:h323 

• video:tel 

These "ENUMservices" indicate that the resource identified by the associated URI is capable of being contacted to 
provide a communication session during which interactive media streams carrying video data can be exchanged. 

9.4.1 .2 "ENUMservices" for Discrete (non-session related) Messages 

This group of "ENUMservices" is intended to indicate that the associated resource is capable of receiving a discrete 
(non-session related) message or document. This group may be selected by a querying client if they want to deliver a 
message (such as a Fax) to a correspondent. (For more information see draft-ietf-enum-msg-01.txt) 

• email:mailto 

This "ENUMservice" indicates that a remote resource can be addressed by the associated URI in order to send 
emails. 

• fax:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of being contacted 
to provide a communication session during which facsimile documents can be sent. 

• if ax: mail to 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of being contacted 
to provide a communication session during which facsimile documents can be sent to an e-mail address. The 
email address is then used in accordance with "Simple Mode of Facsimile using Internet Mail", RFC 3965 [29] 
or "Extended Facsimile using Internet Mail", RFC 2532 [28]. "Full Mode Fax Profile for Internet Mail" is 
applied when it is approved as an Internet standards-track specification. 

For more information see draft-ietf-fax-faxservice-enum-02 (see bibliography). 

• sms:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Short Message Service (SMS). 

• sms:sip, sms:sips 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the SIP protocol 
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sms:mailto 



This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using an e-mail protocol. 

• ems:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Extended Message Service (EMS). 

• ems:sip, ems:sips 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the SIP protocol 

• ems:mailto 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using an e-mail protocol. 

• mms:tel 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the Multimedia Message Service (MMS). 

• mms:sip, mms:sips 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using the SIP protocol 

• mms:mailto 

This "ENUMservice" indicates that the resource identified by the associated URI is capable of receiving a 
message using an e-mail protocol 

9.4.1 .3 "ENUMservices" for Information Source 

This group of "ENUMservices" indicates that the associated resource can act as a source for information. It acts as the 
"opposite" of the "ENUMservices" associated with message sending, in that the latter indicates a source for data whilst 
the former indicates a sink for data. For more information see draft-itef-emum-webft-01. 

• web:http 

• web:https 

These "ENUMservices" indicate that the remote resource identified by the associated URI is capable of 
providing documents when contacted using web protocols; in short, it acts as a web server for the data 
addressed by the associated URI. 

• ft:ftp 

This "ENUMservice" implies that the associated URI identifies a remote resource that provides a file service 
from which an addressed document (or file listing) can be retrieved. 

9.4.1 .4 "ENUMservices" for Service Resolution Services 

This group of "ENUMservices" is used where the ENUM subscriber wants to use a specialized "Service Resolution 
Service" above and beyond ENUM. It can be used where the services available depend on factors that cannot be 
covered in the global ENUM system; for example, the services "advertised" may depend on the person asking, and so 
requires authentication to be performed before any detailed information is returned. 

• sip 

• h323 
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For more information on these "ENUMservices" see RFC 3762 [23] and RFC 3764 [24]. 

• pres 

For more information on Address Resolution for Presence and Instant Messaging see RFC 3861 [25], on 
"ENUMservice" "pres" see I-D draft-ietf-enum-pres. 

9.4.1 .5 "ENUMservices" for Session-oriented Message Exchanges 

This group of "ENUMservices" indicates that the remote resource is capable of engaging in chat sessions 
(i.e. session-oriented message exchanges). It differs from the "ENUMservices" in clause 9.4.1.2 (discrete messages) in 
that the latter group implies a session-oriented message exchange, whilst the former group implies a discrete message 
can be sent to the resource at this contact address. 

• tp:tel 

This "ENUMservice" indicates that a remote resource addressed by the associated URI is capable of involvement in a 
textphone session. This is a group of systems that use the PSTN to transfer character data between compatible 
terminals. These are commonly used by users who have hearing impairment. 

• im:sip 

This "ENUMservice" indicates that the remote resource is capable of engaging in a session-oriented "instant message" 
exchange. 

9.4.1 .6 "ENUMservices" for Instant Information Display - Announcement 

This group of "ENUMservices" indicates that an item of instant information from the ENUM Subscriber is to be 
presented by the ENUM Client to the ENUM User. 

• ann:sip 

• ann:h323 

• ann:tel 

The above "ENUMservices" shall point to recorded announcements: 

• ann:http 

• ann:ftp 

These "ENUMservices" shall point to a webpage containing at least text and voice data. 

As announcements including both text and sound are especially important for people with hearing and visual 
impairments, it is proposed to use a reference to resources holding both kinds of data where possible, either via a web 
page with embedded sound links or a directory (accessed via FTP) that includes both kinds of announcements. 

NOTE: This group is intended to trigger automatic execution. There are significant risks involved in this, due to 
unsolicited onward actions. Clients may wish to consider disabling this feature by default. Further study 
is required during the trials. 

9.4.1 .7 "ENUMservice" for Redirection 

This "ENUMservice" is a special case in that it includes all other "ENUMservices" within it. The goal is to provide a 
default "ENUMservice". This may be used to indicate that the "ENUMservices" supported with a NAPTR are not 
specified in any more detail. In effect, the ENUM Subscriber is asserting that this NAPTR supports ALL 
"ENUMservices". However, in practice it means that further processing (by evaluating the regexp and so constructing 
the associated URI) is needed before the end system can be sure whether to discard the record or not. 

• enum 

NOTE: This "ENUMservice" may either be used by the ENUM Subscriber to forward the ENUM user to another 
subdomain holding his "real" NAPTRs or by the Tier 1 Registry to redirect from one subtree to another. 
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EXAMPLE: $ORIGIN 2.2.2.3.4.el64.arpa. 

* INNAPTR 10 10 "u" "E2U+enum" "!'^+43222(.*)$!tel:+431\l!" . 

This example shows the redirection of a whole subtree within the domain 3.4.el64.arpa in case of 
an area code split. Any number within the area code +43 222 xxxxxxx not having a resource 
record associated with it triggers a query of the ENUM domain associated with the redirected 
number in the new area code +43 1 xxxxxxx. Of course any full E. 164 Number can simply be 
"redirected" with e.g.: 

$ORIGIN0.1.8.7.8.0.1.8.7.8.0.1.8.7.8.el64.arpa. 

INNAPTR 10 10 "u" "E2U+enum" "!'^.*$!tel:+436644204100!" . 

9.4.1.8 "ENUMservice" void 

This "ENUMservice" is also a special case and indicates that the related E.164 number or number range is not assigned 
to an end-user in case of an E. 164 number or a to a communication service provider in case of an E. 164 number range. 
The rationale behind this is to prevent an ENUM clients capable of doing so to route the call to the PSTN for specific 
services (e.g. for voice calls, fax, SMS, MMS, etc.). 

NOTE: The term "routing the call to the PSTN" includes also eventual subsequent queries to Infrastructure 

ENUM. 

• void:mailto 

EXAMPLE 1 : Unassigned number range 

$ORIGIN .0.2.3.4.el64.arpa. 

* INNAPTR 10 10 "u" "E2U+void:mailto" "!'^.*$!mailto:num-info@rtr.at! . 

This example shows that the whole number range +4320 is not assigned. Since there are no 
delegations within the domain, a wild card entry SHALL be used. Any client retrieving this 
NAPTR SHALL immediately display or announce depending on its capabilities "no such number". 

EXAMPLE 2: Default NAPTR record in the enclosing zone 

$ORlGIN .0.1.8.7.8.el64.arpa. 

INNAPTR 10 10 "u" "E2U+void:mailto" "!'^.*$!mailto:num-info@visionng.org! . 

This example shows a default NAPTR for an ENUM -driven number range. E.164 numbers in 
ENUM -driven number ranges are only assigned to an ENUM subscriber if a corresponding entry 
in el64.arpa exists. If a query for ENUM for a given domain returns rcode=NXDOMAlN and a 
second ENUM query for the enclosing domain returned in the authority section returns this 
NAPTR, the client SHALL also immediately display "no such number". See also clause 10.1. 
Since other delegations exist in this domain, a wild card record MUST NOT be used. 

It is a national matter who has the right to enter such records on the different national levels of the tree el64.arpa. 

• void:http, void:https 

These ENUMservices have identical intent and use, with the sole exception that they include a web URL rather than an 
email address. All of these URLs SHALL NOT be used in normal call processing, but may be used only for non-call 
related purposes to indicate a contact for further information on the number or number range in question. 



9.4.2 Additional "ENUMservices" 

These "ENUMservices" require further study prior to implementation. 
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9.4.2.1 "ENUMservices" for Location Information 

This "ENUMservice" indicates that the associated resource can act as a source for location information. It is proposed to 
provide this information in Geography Markup Language (GML). 

• loc:http 

9.4.2.2 "ENUMservices" for Public Key Information 

These "ENUMservices" indicate that the associated resource can act as a source for pubHc key information. 

• key:ldap 

• key:http 

10 Processing of retrieved information by ENUIVI Clients 

10.1 All ENUM Clients 

All ENUM Clients SHALL query the DNS for all NAPTR resource records in the given domain as described in 
clause 9. 

If the query returns a rcode which is NOT or 3, the ENUM client SHALL indicate "query failed". 

If the query returns no NAPTR RR (no data), the ENUM client may either indicate "no data" or return a tel: URI with 
the "enumdi" parameter set (e.g. tel:+43xxxx;enumdi). 

NOTE: The "enumdi" parameter instructs an application client able to establish a communication based on a tel: 
URI, or a client being able to communicate with an application server being able to do so that it SHALL 
NOT query ENUM for this E. 164 number again. The application client or server MAY query 
Infrastructure ENUM, another database or route the call directly to the PSTN. These are in principle all 
application clients providing voice, sms, mms or fax services. If the application client is not capable of 
doing so, it SHALL indicate "no such service" and NOT "unassigned number". For more information on 
the "enumdi" parameter see I-D draft-ietf-iptel-tel-enumdi (see bibliography). 

If the query returns a NAPTR RR with "ENUMservice" "void", the ENUM client SHALL indicate "no such number". 

All ENUM Clients SHALL recognize as a minimum the "ENUMservices" and URIs in clause 9.4.1: 

• This does not imply that an application supporting the given "ENUMservice" field and URI-scheme is 
available and may be launched. 

• Recognition of these "ENUMservice" fields allows the client to use this knowledge to present appropriate 
options. 

All ENUM Clients SHALL first look for "ENUMservice" "enum". If a NAPTR with this "ENUMservice" is found, an 
additional query SHALL be launched for the ENUM domain given by the "tel:" URI Scheme. To prevent endless loops, 
the client SHALL make only a maximum of 5 such redirections. 

If an "ENUMservice" "ann:http" is found, the Application Client SHALL indicate this fact. . ENUM Clients MAY also 
indicate "ann:sip", "ann:h323" or "ann:ter'. 

1 0.2 ENUM enabled Clients for specific applications 

The Clients for specific applications MAY be able to query ENUM directly. These clients are called ENUM enabled 
Application Clients. 

ENUM enabled Application Clients need only support the "ENUMservices" for which they are designed. 

First the ENUM enabled Application client SHALL process the information as described in clause 10.1. 
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Then the ENUM enabled Application Clients SHALL look for NAPTR RR containing any "ENUMservice" supported 
by the application.. If no NAPTR RR containing a usable "ENUMservice" is found, the ENUM enabled Application 
Client SHALL indicate "service not available". 

Further capabilities are up to the specific ENUM enabled Application Client. 

1 0.3 Examples of specific ENUIVI enabled Application Clients 

This clause gives some examples of a possible behaviour of specific ENUM enabled Application Clients. 

1 0.3.1 ENUIVI enabled gateway from the PSTN to the Internet 

A gateway from the PSTN to the Internet may be ENUM enabled to route calls to destinations potentially "published" 
in ENUM. This gateway MAY support only a limited range of ENUMservices, which can be accessed by the PSTN. 

After processing the information retrieved from ENUM according to clause 1 0.1, the ENUM enabled application client 
looks for the specific ENUMservices it supports. This MAY be e.g. "sip", "h323", "voice:sip", "voice:h323", 
"voiceitel", "ifax:mailto", etc. 

If a "voiceitel" is chosen, and the E.164 contained in the "tel" URI is different from the number originally queried, the 
ENUM enabled application client SHALL launch another ENUM query for the number given (as if it had received a 
NAPTR containing the "enum" Enumservice, as described in clause 9.4. L7). To prevent endless loops, the client 
SHALL make only a maximum of 5 such redirections. In the subsequent queries only "voice", "sip" or "h323" 
ENUMservices SHALL be considered. 

If any of these queries returns any "voice" ENUMservice except " voiceitel", this ENUMservice SHALL be used. 

If any of these queries returns a "voiceitel" with the same number as queried or an NXDOMAIN, the call SHOULD be 
processed further by querying infrastructure ENUM, another database or by routing the call directly to the PSTN, if the 
gateway is providing this. If the gateway is not providing this functionality, "no such service" SHALL be indicated. 

If the call is passed on to another network element, the "enumdi" parameter SHALL be set. 

1 0.3.2 ENUM enabled SIP Client 

An ENUM enabled SIP Client should look primarily for "ENUMservice" "sip". If the "ENUMservice" "sip" is found, 
the client should establish a connection to the SIP URI given and start negotiating the service. 

If no NAPTR with "ENUMservice" "sip" is found, the ENUM enabled SIP Chent should look for "ENUMservice" 
"voice:sip" and if available, should establish a voice connection to the given SIP URI. 

Depending on the service provided by the SIP application, the ENUM enabled SIP Client may also look for 
"ENUMservices" "voiceitel", "video:sip" and "videoitel", then for "ENUMservices" " email :mailto", "faxitel" and 
"im:sip". 

1 0.3.3 ENUM enabled H323 Client 

An ENUM enabled H323 client should look primarily for "ENUMservice" "h323". If the "ENUMservice" "h323" is 
found, the client should establish a connection to the h323 URI given and start negotiating the service. 

If no NAPTR with "ENUMservice" "h323" is found, the ENUM enabled H323 Client should look for "ENUMservice" 
"voice:h323" and if available, should establish a voice connection to the given H323 URI. 

Depending on the service provided by the H323 application, the ENUM enabled H323 client may also look for 
"ENUMservices" "voice:tel", "video:h323" and "video:tel", then for "ENUMservices" "emaikmailto" and "fax:tel". 

1 0.3.4 ENUM enabled Email Client 

An ENUM enabled Email Client SHALL look for "ENUMservice" "email:mailto". If this "ENUMservice" is found, the 
ENUM enabled Email Client shall establish a connection to the given mailto URI. 
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If the ENUM enabled Email Client is capable of dealing with public keys and the "ENUMservice" "key:ldap" is found 
in addition, the ENUM enabled Email Client may indicate that an encrypted mail may be sent. 

1 0.3.5 ENUM enabled Web Browser 

An ENUM enabled Web Browser SHALL look for "ENUMservices" "web:http" or "web:https" and display the given 
web-page given within the URL If the Web Browser is capable of processing the FTP protocol, it MAY also look for 
"ENUMservice" "ft:ftp". 

1 0.3.6 ENUM enabled FTP Client 

An ENUM enabled FTP Client SHALL look for "ENUMservice" "ft:ftp" and retrieve the file given within the URL 

1 0.3.7 ENUM enabled FAX Client 

An ENUM enabled FAX Client SHALL look for "ENUMservice" "faxitel" and send the FAX message to the E.164 
number given in the URL It SHALL also look for "ENUMservice" "ifax:mailto" and send the FAX message as e-mail 
to the URI given. 

1 0.3.8 ENUM enabled SMS Client 

An ENUM enabled SMS CUent SHALL look for "ENUMservice" "smsitel" and send an SMS message to the E.164 
number given in the URI. In addition, the SMS Client SHALL look for "emsitel" and "mmsitel", as SMS forms a subset 
of these services, and so an SMS may be delivered using them. The ENUM enabled SMS Client may either be an 
application having web-access to an SMS centre, or an IP-enabled (e.g. GPRS) mobile phone, or be a SMS centre on its 
own. 

An ENUM enabled SMS CHent SHALL look for "ENUMservice" "sms:sip" and send a SIP message to SIP URI given. 
In addition, the SMS Client SHALL look for "ems:sip" and "mms:sip", as SMS forms a subset of these services, and so 
an SMS may be delivered using them. The ENUM enabled SMS Client may either be an application using the SIP 
protocol or be a SMS centre on its own. 

An ENUM enabled SMS Client SHALL look for "ENUMservice" "sms:mailto" and send an e-mail to SIP URI given. 
In addition, the SMS Client SHALL look for "ems:mailto" and "mms:mailto", as SMS forms a subset of these services, 
and so an SMS may be delivered using them. The ENUM enabled SMS Client may either be an application using an 
e-mail protocol or be a SMS centre on its own. 

10.3.9 ENUM enabled Location Client 

An ENUM enabled Location Client SHALL look for "ENUMservices" "loc:ldap" or "loc:http" and retrieve location 
information. The location information may e.g. be given in Geographic Mark-up Language (GML). The application 
client may either be a stand-alone application displaying the location information to the user or an embedded 
application using the location information for further processing (e.g. driving instructions, directions). 
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Annex A (informative): 

Background to NAPTR Resource Records 

This annex gives a background to "NAPTR" Resource Records and the "ENUMservice" field and is mainly derived 
directly from the referenced RFCs. 

The ENUM System as defined in RFC 3761 [16], which obsoletes RFC 2916, discusses the use of the DNS for 
identifying available services connected to an E.164 number. Through the transformation of E. 164 numbers into DNS 
names and the use of existing DNS services, especially the NAPTR records as defined in RFC 3403 [20], one can look 
up what services are available for the related E.164 number. 

ENUM is about a specific usage of "NAPTR" Resource Records within the Domain Names System (DNS), as 
explained within the Dynamic Delegation Discovery System (DDDS). The DDDS is specified in a series of documents 
(RFC 3401 [18] to RFC 3405 [21]). 

The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, in order to 
support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored 
within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. 

An introduction and overview to the DDDS is given in "Dynamic Delegation Discovery System (DDDS) Part One: The 
Comprehensive DDDS" (RFC 3401 [18]). In order to fully understand any document in this series it should be noted 
that all other documents should also be read. 

"Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" 
(RFC 3403 [20]) describes the way in which the Domain Name System (DNS) is used as a data store for the Rules that 
allow a DDDS Application to function. It does not specify any particular application or usage scenario. The present 
document also obsoletes RFC 2915 [27]. ENUM is a particular "application" and described in RFC 3761 [16]. 

The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified in RFC 3403 [20] was originally 
produced by the IETF URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a 
Uniform Resource Identifiers (URI) (RFC 3986 [12]) could be decomposed in such a way that they could be changed 
and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by 
a client program to rewrite a string into a domain name. 

Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to 
be encoded in a rather small DNS packet. They are a combination of a POSIX Extended Regular Expression and a 
replacement string similar to Unix sed-style substitution expression, for the syntax see RFC 3402 [19]. 

In the case where two "Applications" may use the same database (which is actually the case with DNS and the ENUM 
and URI Resolution Applications), there is a chance of collision between rules where two NAPTR records appear in the 
same domain but they apply to more than one Application. Different ways exist to avoid collisions, the way chosen in 
ENUM is to use different values in the Services field (see below), so a record from another Application will be ignored 
since it does not apply to the Service fields in question. 

The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35. 
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The packet format for the NAPTR record is as follows: 

111111 
0123456789012345 
+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
I ORDER I 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
I PREFERENCE I 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ FLAGS / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ SERVICES / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ REGEXP / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 
/ REPLACEMENT / 

/ / 

+ — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + — + 

<character-string> and <domain-name> as used here are defined in RFC 1035 [4]. 

"ORDER" field 

A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately 
represent the ordered list of Rules. Since no ordered lists are used within the ENUM Field trials, this field is not 
applicable (see also clause 9.3). 

"PREFERENCE" field 

Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the 
DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order 
values SHOULD be processed, low numbers being processed before high numbers (this field is applicable in the 
ENUM field trials, see clause 9.3). 

"FLAGS" field 

A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. 
Flags are single characters from the set A-Z and 0-9. The case of the alphabetic characters is not significant. The field 
can be empty. It is up to the "Application" specifying how it is using this Database to define the Flags in this field. It 
must define which ones are terminal and which ones are not. Therefore RFC 2916bis specifies that at this time only one 
flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [12]. For more 
information see clause 9.3. 

"SERVICES" field 

A <character-string> that specifies the Service Parameters applicable to this delegation path. It is up to the 
"Application" Specification to specify the values found in this field. 

Therefore RFC 3761 [16] defines this field as follows: 

Service Parameters for this "Application" (ENUM) take the following form and are found in the Service field of the 
NAPTR record. 

service_field = "E2U" 1 *(servicespec) 
servicespec = "+" ENUMservice 
ENUMservice = type 0*(subtypespec) 
subtypespec = ":" subtype 
type = 1*32( ALPHA/DIGIT) 
subtype = 1 *32( ALPHA/DIGIT) 

In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) 
followed by 1 or more "ENUMservices" which indicate what class of functionality a given end point offers. Each 
"ENUMservice" is indicated by an initial "+" character. 
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An "ENUMservice" MUST be registered with the lANA via a description in an RFC. "ENUMservices" specifications 
contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be 
returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the 
"ENUMservice" and URI schemes or protocols. The mapping, if any, has to be made explicit in the present document 
for the "ENUMservice" itself. A registration of a specific "type" also has to specify the "subtypes" allowed. 

A registered "ENUMservice" must be able to function as a selection mechanism when choosing one NAPTR resource 
record from another. That means that the registration MUST specify what is expected when using that very NAPTR 
record, and the URI which is the outcome of the use of it. 

Specifically, a registered "ENUMservice" MUST specify the URI scheme(s) that may be used for the "ENUMservice". 

Since there are few "ENUMservices" registered with lANA yet, the definition of this field is one of the main purposes 
of the present document. 

"REGEXP" field 

A <character-string> containing a substitution expression that is applied to the "original string" held by the client in 
order to construct the next domain name to lookup. See the DDDS Algorithm specification (RFC 3402 [19]) for the 
syntax of this field. In case of the ENUM Trials, the regexp always produces an URI, for more information see 
clause 9.3. 

"REPLACEMENT" field 

This field is not used within ENUM Trials. 

RFC 3761 [16] defines in addition how to get the "original string" mentioned above and how to access the database (for 
more information on the terms used see the DDDS RFCs): 

• That the Application Unique String (AUS) for ENUM is a fully qualified E. 164 number minus any non-digit 
characters except for the "+" character which appears at the beginning of the number. 

• That the First Well Known Rule for ENUM is the identity rule, which gives the original string. 

• That the output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 
"absoluteURI" production in the Collected ABNF found in RFC 3986 [12]. 

• That at present only one DDDS Database is specified for ENUM. "Dynamic Delegation Discovery System 
(DDDS) Part Three: The DNS Database" (RFC 3403 [20]) specifies a DDDS Database that uses the NAPTR 
DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names. 

The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters 
except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name 
according to this algorithm: 

1) Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the 
Key "H-4689761234". This step would simply remove the leading "+", producing "4689761234". 

2) Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4. 

3) Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4. 

4) Append the string ".el64.arpa" to the end. Example: 4.3. 2.1.6.7. 9.8. 6.4.el64.arpa. 

This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, 
produces new keys in the form of domain-names from the DNS. 
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